\section{Decisiones de arquitectura}
En esta sección describiremos las principales decisiones de arquitectura que se tomaron para cumplir con requerimientos y 
atributos de calidad. Como veremos predomina el estilo pipe and filter, pero también se usan diferentes estilos.

Para ver con exactitud todo el proceso y explicación de la arquitectura, se debe leer la sección 4(arquitecturas contra casos de uso)
se explica en detalle el funcionamiento.

\subsection{Adaptación a otros dispositivos}

Un problema a solucionar fue el requerimiento que la aplicación deba correr en distintos dispositivos. Para que esto fuera posible
se decidió tener componentes que sirvan de adaptadores para cada dispositivo como puede verse en la figura \ref{inter}, 
donde hay un adaptador de dispositivos para input y output, los cuales se comunican con el dispatcher para otorgar algún dato
y procesarlo y también reciben del selector de salidas para poder obtener un resultado.

A su vez para determinar comandos de voz o hacerlo compatible con los anteojos, contamos con traductores de voz a comandos que 
luego serán ejecutados y un adaptador para los drivers de anteojos y que estos puedan comunicarse con el mismo.

Esto nos lleva a la próxima decisión que tomamos, que en parte fue sugerida por la cátedra, de tener una componente que se 
encargue de derivar pedidos a otras dependiendo del tipo de pedido, esta componente es el Dispatcher.

A su vez de manera similar cuando un resultado es obtenido, depende del tipo de pedido, el selector de interfaz de salida decide
a quien derivarlo.



\subsection{Los entrenamientos}

En referencia a los entrenamientos la arquitectura está guiada por la necesidad de almacenar un entrenamiento completo con la 
información pertinente, brindar la posibilidad de seleccionarlos, y almacenar datos de forma segura para la Secretaría de Deportes.

Para poder tener en cuenta las tres cosas, tener consistencia y flexibilidad en caso de necesitar cambiar el orden de procesos
o flujo de datos, usamos un estilo pipe and filter. Como puede verse en la figura \ref{monitor} donde los datos fluyen del Actualizador
de Posición al Calculador de Velocidad y luego al Auditor, para finalmente guardarse en Open Stack.

En caso de finalizar un entrenamiento, el estilo es distinto puesto que primero se verifica disponibilidad, de no haberla se guarda 
en un buffer auxiliar. Si el manager está disponible se almacenará en el servidor, solicitando un pedido al mismo y esperando
confirmación.

En caso de elegir entrenamientos la rutina es similar al caso anterior, solo que el estilo es Call Return para poder devolver
las opciones, pero de igual manera se verifica disponibilidad y en caso de haberla se traen todas las opciones, si no sólo algunas.

\subsection{Las redes sociales}

Nos pareció fundamental que nuestra aplicación sirva para redes sociales, y se adapte a la mayoría de ellas.
Para eso decidimos no limitarnos a una en particular y tener una componente encargada de adaptar mensajes que llegan
de distintas redes sociales como pueden ser Facebook o Twitter. Esta componente es el Adaptador de Redes Sociales (ver figura \ref{redsoc}).
Es una componente que sabe interpretar los mensajes que llegan y los deriva al Filtrador de Mensajes donde se hacen los
filtros correspondientes y se llevan a la interfaz de salida que corresponde.

El otro tema relevante fue el de visualizar a los amigos corredores. Para esto decidimos dedicar una porción del servidor
para almacenar los registros de  las ultimas posiciones de cada usuario.

A su vez una componente dedicada a la búsqueda de posiciones de amigos(Friend Tracker), es la encargada de solicitar al manager 
de entrenamientos las últimas  posiciones de los amigos.

Para cumplir con performance y seguridad decidimos que el servidor tenga permisos del usuario para buscar sus amigos en las
redes sociales. Una vez que tiene permisos ante una solicitud del Friend Tracker, se buscan las posiciones de los amigos en 
un registro especial del servidor, exclusivamente dedicado a las ultimas posiciones, y así obtenerlos rápido para 
mostrar en el mapa.

